Bug Fix

The release workflow failed in run 25562543881 (job 75053678651) when resolving the newly created release’s databaseId immediately after gh release create. This change makes release ID resolution resilient to transient post-create API inconsistency.

What was the bug?

After creating a release, the workflow immediately called:

gh release view "$RELEASE_TAG" --json databaseId --jq '.databaseId'

In the failing job, that lookup intermittently failed at step 6:12, causing the release job to exit.

How did you fix it?

• Release ID resolution retry
  • Added bounded retry logic (MAX_ATTEMPTS=5) for release ID lookup.
• Backoff strategy
  • Added exponential backoff (2^attempt seconds) between retries.
• Error classification
  • Retries only on expected not-found/404 style responses.
  • Fails fast on non-retryable errors (e.g., auth/network/systemic failures).
• Workflow artifact update
  • Recompiled the lock workflow so the runtime definition includes the new retry behavior.

MAX_ATTEMPTS=5
RELEASE_ID=""
for attempt in $(seq 1 "$MAX_ATTEMPTS"); do
  set +e
  release_view_output=$(gh release view "$RELEASE_TAG" --json databaseId --jq '.databaseId' 2>&1)
  release_view_status=$?
  set -e

  if [ "$release_view_status" -eq 0 ] && [ -n "$release_view_output" ]; then
    RELEASE_ID="$release_view_output"
    break
  fi

  if ! echo "$release_view_output" | grep -qiE "not found|404"; then
    echo "Error: Failed to resolve release ID for $RELEASE_TAG"
    echo "$release_view_output"
    exit 1
  fi

  [ "$attempt" -lt "$MAX_ATTEMPTS" ] && sleep $((2 ** attempt))
done

Testing

This change specifically targets the failure mode observed in job 75053678651: release creation succeeds, but immediate ID resolution may be transiently unavailable. The new logic preserves fast success when available and retries when the ID is not yet visible.